home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5670 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.3 KB
  1. Path: goanna.cs.rmit.EDU.AU!not-for-mail
  2. From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
  4. Subject: Re: Hungarian notation
  5. Date: 6 Feb 1996 10:16:21 +1100
  6. Organization: Comp Sci, RMIT, Melbourne, Australia
  7. Message-ID: <4f6345$jll@goanna.cs.rmit.EDU.AU>
  8. References: <4cud8f$gup@news.netvision.net.il>
  9. NNTP-Posting-Host: goanna.cs.rmit.edu.au
  10. NNTP-Posting-User: ok
  11. X-Newsreader: NN version 6.5.0 #0 (NOV)
  12.  
  13. Douglas Evan Cook <cookd@cs.byu.edu> writes:
  14. >Ah, but the ADT *did* specify that the file format would remain the 
  15. >same.
  16.  
  17. There seems to be some confusion here.
  18.  
  19. A file format is a *concrete* data type.
  20.  
  21. It is possible to hide the details by writing an ADT.
  22.  
  23. >And not all users of the applications are using the same platforms 
  24. >- some are running on 386's with 386 DOS extenders, some are running with 
  25. >286 extenders, some are running on overlaid versions of the program done 
  26. >for straight DOS, some are running on Windows NT, and some are running on 
  27. >non Intel based machines.
  28.  
  29. There are three aspects here.
  30.  
  31. (a) Portability of code.
  32.     If programs access the file(s) in question _only_ through the ADT
  33.     (which hides the file format), then the ADT has to be reimplemented
  34.     for different file formats, but the rest of the programs port with
  35.     no change.
  36.  
  37. (b) Portability of data.
  38.     I would really like to see you port a data file containing binary coded
  39.     floating-point numbers from a 386 to a 680x0, PowerPC, SPARC, &c.
  40.     Now you might think that straight "strings" can be ported with no
  41.     trouble, but even that is hard.  If your data were written on a
  42.     machine using IBM Code Page 437 and read on a machine using
  43.     Code Page 850, you had *better* use a conversion, same hardware or not!
  44.  
  45.     This is a serious issue.  Almost weekly I run into text files that have
  46.     had their end of line convention converted {CR, LF, CR-LF} but not the
  47.     text characters.
  48.  
  49. (c) Access to one copy of data in a heterogeneous network
  50.     You cannot realistically do this without hiding the file format.
  51.     XDR is _the_ big player here, and NetCDF is of great interest.
  52.     Typically, on-the-fly conversion is a fraction of the cost
  53.     of I/O across the network.
  54.  
  55. >The users expect to be able to transfer files between each platform.
  56. >And so we compile, but in each platform we don't 
  57. >want to have to modify the ADT's because of compiler dependancies.  So we 
  58. >have the ADT's depend on typedef equivalents, so that when we need to 
  59. >compile for a new platform we only need to change 10-12 lines in the base 
  60. >definition file.
  61.  
  62. You keep on using "ADT" in a very puzzling way.
  63. It would clarify things a lot if you would _show_ us these 10-12 lines.
  64. If, as I suspect, it consists of things like
  65.     typedef unsigned short u16;
  66. then you are _not_ dealing with ABSTRACT data types at all, and
  67. I have some bad news for you.
  68.  
  69. Suppose I have a file format in which one field is specified to be a
  70. 16-bit little-endian unsigned integer.
  71. (a) I have used a really wonderful machine in which there was no such
  72.     thing as an unsigned integer.
  73. (b) I have used several machines in which there was no such thing as
  74.     a 16-bit storage format.
  75. (c) Many of the machines I have used require "natural" alignment, e.g.
  76.     K-byte entities must have addresses that are multiples of K, for
  77.     K = 1, 2, 4, 8.  On an 80*86, you might not have thought of this,
  78.     as that architecture supposed unaligned load/store.
  79. (d) I am using a terminal emulator on one machine to post from another.
  80.     Neither of those machines is little-endian.  (Which is a pity.  I
  81.     like little-endian, and feel that the image of little-endian has
  82.     been tarnished by association with Intel.)
  83.  
  84. What I am saying is that _if_ your program is like this:
  85.  
  86.     typedef <something> u16;
  87.  
  88.     u16 x;
  89.     fwrite(&x, sizeof x, 1, output_stream);
  90.     ...
  91.     fread(&x, sizeof x, 1, input_stream);
  92.  
  93. then there is literally no possible typedef on the Mac (68040) or Sun (SPARC 8)
  94. that I am using that could make this work with a data file written on an 80*86.
  95.  
  96. By the way, if I wanted to read and write byte streams encoding numbers,
  97. arrays, and records, in Ada I would need *no* variation from platform to
  98. platform at all, not even 10-12 lines.  Done right, that is.
  99.  
  100. >> A clean way to deal with this would be to convert the data files. Done
  101. >> properly, this wouldn't inconvenience users.
  102.  
  103. This conversion can be done when a file is moved to a different machine
  104. (which permits the use of "native" data representations in the file,
  105.  but gets in the way of cross-network sharing)
  106. or it can be done whenever the file is accessed
  107. (which permits cross-network sharing, but not the use of "native"
  108.  data representations in the file).
  109.  
  110. Note, by the way, that there is no requirement for two compilers for language
  111. X on machine Y to represent basic data types the same way.  (For example,
  112. C's "long double" might be stored in 80 bits, 96 bits, or 128 bits, all
  113. depending on which compiler you use.)  On one of the machines I used, the
  114. vendor introduced long double with 96 bits, then switched over to 128.  Any
  115. data files depending on 96 bit format would have been a pain to deal with...
  116.  
  117. -- 
  118. "conventional orthography is ... a near optimal system for the
  119.  lexical representation of English words." Chomsky & Halle, S.P.E.
  120. Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
  121.